NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part2/10406

Internet Message Format | 1996-08-05 | 4.5 KB

Path: newshost.netinfo.com.au!usenet
From: Alan Brain <[e-mail]>
Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++
Subject: Re: C/C++ knocks the crap out of Ada
Date: 7 Mar 1996 08:27:36 GMT
Organization: Netinfo Pty Ltd - Canberra Australia
Message-ID: <4hm6lo$[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <4hakfl$[e-mail]> <[e-mail]>
NNTP-Posting-Host: dialup7.dynamite.com.au
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 1.2N (Windows; I; 16bit)

[e-mail] (Kazimir Kylheku) wrote:
>In article <4hakfl$[e-mail]>,
>Alan Brain  <[e-mail]> wrote:
> >[e-mail] (Kazimir Kylheku) wrote:
> >
> >
> >>You are confusing the language specification with the implementation. The C
> >>specification does not call for the ability randomly access memory. The only
> >>way to legally manufacture pointers is by taking the addresses of named
> >>objects, using the standard defined function malloc() or through pointer
> >>arithmetic (adding an integral displacement to an existing pointer---an
> >>operation which yields undefined results if you try to create a pointer outside
> >>of an object). You aren't even legally allowed to subtract two pointers that
> >>don't reference the same object, even if they have compatible types.
> >
Re: Soft Failures etc

>Ada compiled code will catch this? My ass.

Always? Nope. Sometimes? You bet. Usually? - Good question. Sometimes immediately, but
sometimes only after much useless computation - you give examples below that only a real
smart design would catch quickly:

>What if the parameter is altered in such a way that it stays within the index?
>I suppose that you have a proof that this is safer and more reliable. After
>all, if a mechanical arm is safer when it stays within certain physical limits,
>surely an array index or pointer inside a digital computer is safer when it
>stays within bounds, right?
>
>Keep dreaming in your imaginary world...

..and there are a million other failure modes that mere strong type checking will not
catch. Just as having good brakes will not stop the gas tank exploding. BUT... if (unlike
C) you don't have to write 2 lines of code to error-check 1 line that actually does
something, only 1 line for every 2-5 [have you ever seen really safe Ada code? nearly
every couple of statements have their own block and exception handlers!], the chances that
your error-correction will be relatively safe increases. The compiler does the work,
instead of (more) fallible mortals like myself.

> >To give a concrete example, I - along with some very inexperienced programmers
> >- recently wrote a Threat Evaluation and Weapon Assignment segment. One which
> >would kill people if it didn't work exactly right, either by shooting at
> >friendlies, or allowing a missile through to hit the ship.
>
>That's why they assigned you to it, along with some very inexperienced
>programmers!  Right on. Glad to know tax dollars are hard at work.

Yup, brought me out all the way from Australia to do it too. Just not for the US...

> >That's the key to success in my experience. Ada 83 code cannot be Bug-Free,
> >but it can be Bug-Resistant. C - except in certain ways, and with an
> >increase of up to 10 times the coding effort - can't.
>
>How do you know that? Most of the kinds of things you describe (e.g. range
>checking) can be handled by a specialized compiler.

Correct. But then would it be standard C anymore? With a specialised compiler, you could
add strong typing, object inheritance, multitasking, generic structures, and while you're
at it, change the syntax to make it more readable hence understandable hence safer. You
could write a super-lint that not only did the tests but even inserted GOTOs ( ie raised an
exception) at the right places whenever an error could be detected. To make it readable,
you'd have to add a few reserved words, change the GOTOs to some other name, and so on.
You could also write a validation suite that tested this super-lint that did all of the
above.

But I think using Ada 83 would be a little easier...OK, the code is NOT in Ada 83 (though
an Ada 83 compiler will compile it) It's in Safe C, and requires a specialised C compiler
with all the above features to munge it. Coincidentally, this specialised C compiler will
also handle Ada 83 code. But it's not Ada 83, it's safe C, just one more variant of the
totally-portable C family.